perf(sdk): stop repeating bundle hashing and teardown state reads - #12974

Part of #12882.

## Failure

The pinned `kreuzwerker/docker` provider waits 2 s before every
`docker_network` read and after every removal. Every runtime plan,
apply, export, or destroy reads the network once it exists, and a
destroy also waits for the removal. Only the `remote_service` lifecycle
tests deploy a service with a Docker network: the SSH simulator is the
only fake engine that serves `/networks`.

I counted the network reads per test from a request log in the SSH
simulator (local `linux_arm64` bundle; the logging is not part of this
change). The 12 tests made 75 reads, about 150 s of their 404 s of test
time:

| Test | Reads |
|---|---|
|
`managed_bearer_storage_or_key_damage_stops_plan_and_apply_without_changing_bindings`
| 13 |
|
`remote_model_reapply_and_drift_keep_bindings_and_stop_on_observation_failure`
| 11 |
|
`remote_ollama_reapply_and_drift_keep_bindings_and_stop_on_observation_failure`
| 11 |
|
`managed_bearer_credentials_survive_recovery_reapply_and_replacement_outside_state`
| 10 |
|
`managed_pi_applies_without_generation_and_refused_sandbox_changes_keep_intent`
| 9 |
|
`managed_bearer_replacement_cleanup_recovers_and_teardown_accepts_both_identities`
| 7 |
|
`remote_model_apply_recovers_failed_creation_and_lost_process_or_cache_keeping_data`
| 7 |
|
`remote_ollama_apply_recovers_failed_creation_and_lost_process_or_cache_keeping_data`
| 7 |
| partial-destroy and pulled-image tests (4) | 0 |

Several tests created and destroyed a runtime only to repeat checks that
another scenario already ran against the same kind of runtime.

## Decision

Run each check against one runtime per scenario, and only once. The
Docker provider is unchanged.

| Before | After |
|---|---|
|
`remote_model_apply_recovers_failed_creation_and_lost_process_or_cache_keeping_data`
| Removed. vLLM failed-creation, startup, lost-process, and cache
recovery run in
`managed_bearer_credentials_survive_recovery_reapply_and_replacement_outside_state`,
against the same vLLM runtime with a bearer. Present-image compatibility
runs in the Ollama and Pi tests, and the pull-policy plan runs in the
Ollama test. |
| `remote_ollama_apply_recovers_…` and
`remote_ollama_reapply_and_drift_…` |
`remote_ollama_recovers_reapplies_and_stops_on_observation_failure_keeping_data`:
recovery, then export and reapply, the transport failure, and teardown
against the recovered runtime. The readiness gate, compute replacement
plan, and pull-policy reapply do not depend on the runtime kind and run
against vLLM in `remote_model_reapply_and_drift_…`.
`managed_installers_accept_current_runtime_readiness_without_collecting_model_files`
in `nemoclaw-provider` covers each runtime's readiness observation. |
| `managed_bearer_storage_or_key_damage_…` and
`managed_bearer_replacement_cleanup_…` |
`managed_bearer_cleanup_recovers_damage_keeps_bindings_and_teardown_accepts_both_identities`:
the daemon retargeting, credential-volume damage, and insecure-key
checks run against the state that replacement cleanup settles, before
the teardown with both identities. |
| Missing, foreign, and substituted credential volumes through CLI plan
and apply | New
`service_storage::missing_foreign_or_substituted_storage_stops_plan_and_apply_without_changing_state`
contract test, for both storage kinds, through pinned OpenTofu against a
fake engine. The lifecycle test keeps one substituted volume to show the
CLI stops before changing bindings. |
| Pi: failed-creation recovery, then an export after the last refusal |
Pi applies once; the bearer and Ollama tests own recovery. The export
after the last refusal is dropped: the intent is byte-identical to the
one the earlier export already reproduced, and the destroy that follows
reads the same state. |

The partial-destroy and pulled-image tests are unchanged.

## Validation

- Local `linux_arm64` run of `remote_service`, same request log:

  | | Tests | Network reads | Summed test time | Wall (4 threads) |
  |---|---|---|---|---|
  | Before | 12 | 75 | 404 s | 110 s |
  | After | 9 | 48 | 280 s | 97 s |

After the change, by test: vLLM reapply 11, Ollama 9, bearer credentials
10, bearer cleanup and damage 12, Pi 6.
- The new contract test asserts each refusal reason (`bound persistent
storage is absent; recreation forbidden`, `observed ownership,
generation, or durable identity changed`).
- `remote_service` and `service_storage` lifecycle tests pass locally;
`cargo fmt --all --check` and `cargo clippy --workspace --all-targets --
-D warnings` are clean.
- `v1` at a49fc77 does not compile the provider contract tests
(`kubernetes_lifecycle.rs`). This branch carries the same fix as #12981
in its own commit so CI can run, and merging `v1` after #12981 lands
leaves one copy.
- CI lifecycle JUnit reports from run
[38100630144](https://github.com/NVIDIA/NemoClaw/actions/runs/38100630144),
compared with the `v1` run for #12974
([38098264065](https://github.com/NVIDIA/NemoClaw/actions/runs/38098264065)),
the latest `v1` run whose lifecycle tests ran. Cells are partition wall
seconds / summed test seconds / `remote_service` summed seconds:

  | Partition | Before | After |
  |---|---|---|
  | linux_arm64 / 1 | 198.8 / 788 / 175 | 200.2 / 795 / 171 |
  | linux_arm64 / 2 | 178.0 / 711 / 252 | 149.3 / 587 / 120 |
  | linux_amd64 / 1 | 221.0 / 878 / 209 | 208.0 / 825 / 186 |
  | linux_amd64 / 2 | 174.0 / 696 / 247 | 165.6 / 654 / 142 |

`remote_service` went from 427 s to 291 s summed on linux_arm64, and
from 456 s to 328 s on linux_amd64. Across the 9 `Rust desired-state`
runs before #12974, it ranged 446–454 s on linux_arm64. The network read
counts above come from the local request log; CI runs the same commands.
The linux_arm64 lifecycle step is still bounded by partition 1, which
kept its share of the `remote_service` tests and did not get shorter;
partition 2 dropped 29 s.